Skip to main content

Git CLI Fundamentals


Best Practices
  • Pull the newest version of a branch before you start work and before you push
  • Create branches of existing projects for fixes and experiments that you want to work on
  • Commit changes to your working branch often and with descriptive messages of what you changed
  • Merge your branch to the main working branch frequently to avoid large conflicts

Typical Workflow​

  1. Clone the remote repository you want to work on
  2. Create a branch for your edits
  3. Update repository files/folders and commit your changes
  4. Push your branch and commits to the remote repository
  5. Login to Gitlab and initiate a merge request to the main branch to propogate your updates

Initializing a new local repository​

If you are creating a brand new Git project, this can be done by "initializing" the current folder with the following command:

git init
tip

After creating a new local repository, you will need to point it to where the remote version lives:

git remote add origin https://gitlab/<GROUP>/<PROJECT>
git branch --set-upstream-to=origin/main

Cloning an existing remote repository​

  1. First, change directories to a staging folder for your Git projects - in this case, /cvah/git/:

    cd /cvah/git/
  2. Clone the repository you want to work on from the DIP Gitlab instance to your local filesystem:

    git clone https://gitlab/<GROUP>/<PROJECT>
example


Creating/Switching Branches​

note

Working from the main branch is not recommended unless you are creating a new project or are the only one expected to work from the project.

  1. First, change directories into the repository you want to work from:

    cd /cvah/git/<LOCAL_REPOSITORY>
  2. Create a new branch, then use checkout to switch to it:

    git branch <NEW_BRANCH_NAME>
    git checkout <NEW_BRANCH_NAME>
example


Staging and Committing changes​

note
  • All commits remain local until they are pushed to the remote (Gitlab) repository.
  • You should create a different commit for every unrelated change, while grouping related changes into a single commit.
  • A commit is like saving a file - you should do it often and document what was changed in the commit message.
  1. First, change directories into the repository you want to work from:

    cd /cvah/git/<LOCAL_REPOSITORY>
  2. Check to see which files/folders have been created/changed since the last commit:

    git status
  3. Next, specify the files and/or folders (recursive) that you want to add to the "staging area" for the commit:

    git add <FILE(S)/FOLDER(S)>
    tip
    • To add all files:
      git add .
    • To add files interactively:
      git add -i
    • To add changes only from all tracked (pre-existing) files and not new files:
      git add -u
  4. After the files/folders that you created/changed have been added to the "staging area", commit the changes with a descriptive change log:

    git commit -m "<COMMIT_MESSAGE>"
    example


Pulling changes from the remote repository​

In the case that the remote Gitlab repository has been changed, you will need to pull those changes to sync your local repository:

git pull
troubleshooting

If you perform a git pull and there is a conflict between changes in the remote repository and changes in your local files, Git will attempt to merge these changes automatically. However, if Git cannot resolve the differences automatically (which often happens when the same lines in the same files have been changed differently in the two versions), it will result in a merge conflict where the following will occur:

  1. Git Marks the Conflict: Git will pause the merge and mark the conflicted files in your working directory to indicate that there are conflicts that need manual resolution.

  2. Conflict Indicators: Inside the conflicted files, Git will insert visual markers that delineate the conflicting changes, such as <<<<<<<, =======, and >>>>>>>. The content between <<<<<<< HEAD and ======= is your local change, and the content between ======= and >>>>>>> <COMMIT_HASH> is the incoming change from the remote.

  3. Manual Conflict Resolution: You must manually edit the files to resolve the conflicts. This involves deciding whether to keep your local changes, the remote changes, both, or some combination of the two.

  4. Mark as Resolved: After resolving the conflicts in each file, you will need to stage the files (git add) to mark them as resolved.

  5. Complete the Merge: Once all conflicts are resolved and the changes are staged, you can complete the merge process with a commit (git commit) - Git will typically provide a pre-populated commit message for the merge.


Pushing commits to the remote repository​

  1. View the currently configured remote repository URL(s):

    git remote -v
    tip
    • origin is the alias name for the remote URL thats back to where the local repository will push to/pull from by default.
    • If the origin URL needs to be changed, this can be done with the following command:
      git remote set-url origin https://gitlab/<GROUP>/<PROJECT>
    • If no remote is configured, you can add origin with the following command:
      git remote add origin https://gitlab/<GROUP>/<PROJECT>
  2. Push all of your commits to the the remote repository:

    git push origin <BRANCH_NAME>
    tip
    • If you created a new remote, you have to specify it as the new "upstream" that your branch points to - otherwise you will get an error when trying to push
      git branch --set-upstream-to=origin/<BRANCH_NAME>

Merging branches​

note

The git merge command only merges local repositories and does not work for remote Gitlab repositories. Instead, you must login and use the Gitlab web UI to initiate a merge request.

Merging is used to combine the histories of two branches in your Git repository. When you merge one branch into another, you're integrating the changes from one branch into another.

  1. First, checkout the target branch you want to merge into:

    git checkout <TARGET_BRANCH>
  2. Next, merge the source branch into the target branch:

    git merge <SOURCE_BRANCH>